sorry for the long delay. i think this should be ok now - i've rebased and thinned out the PR.

hrm. couple minor issues i found that i'm working through rn

alright. fixed a stale lock bug and added a couple tests around that.

@selimacerbas ?

Thanks @crankycoder, sorry for the delay on my side. The split looks great, the stale-lock fix is a good catch, and the tests are exactly what we needed (especially the port-reuse scenario in section 4 of lock_test.lua). Two small things before merge, plus context on a follow-up.

Before merge

1. README security warning. When a user sets host = "0.0.0.0", they expose more than the rendered preview. Anyone on the same network can:

• read content.md (the markdown buffer being edited)
• hit /__live/inject?event=reload&data=... to trigger reloads or inject scroll events into the user's browser tab (the endpoint has no auth)

Could you add a > [!WARNING] block in the Network section saying something like:

> [!WARNING]
> Binding to `0.0.0.0` exposes the preview server (and the current
> markdown buffer) to anyone on the same network. The live-reload
> control endpoints are currently unauthenticated. Only use this on
> trusted networks. Prefer a one-shot SSH tunnel otherwise.

2. Windows verification. The PID-aliveness check uses uv.kill(pid, 0). CI only runs on ubuntu-latest. libuv's uv_kill should handle signal 0 on Windows (it maps to OpenProcess + WaitForSingleObject), but I'd like to confirm before merging. Either add windows-latest to the matrix, or share a quick screen-grab from Windows nvim showing :lua print(vim.loop.kill(vim.fn.getpid(), 0)) returning 0 for alive.

Follow-up I'll handle separately

I'm going to add token auth in live-server.nvim, Jupyter style. Random 128-bit token at server start, embedded in index.html, gated on all sensitive endpoints, written to the lockfile (mode 0600) so secondary instances can still hit /__live/inject. That makes host = "0.0.0.0" actually safe to recommend. Bigger change, separate PR in the sibling repo, no churn for your PR here. When it lands I'll soften the README warning.

Once the warning is in and Windows is confirmed, this is good to go. Thanks again for the patience and the tests.

Thanks @crankycoder, the README warning is in (the inline **⚠️ Warning:** formatting works fine, no need to change to > [!WARNING]). One real problem with the lock.lua change though, and a heads-up on conflicts.

lock.lua is_pid_alive regression

I tested locally (vim.loop.kill(99999999, 0) returns nil ESRCH, kill(self_pid, 0) returns 0) and the new version reintroduces the exact bug your own section 4 test was designed to catch. Walking through:

function M.is_pid_alive(pid)
    local ok = uv.kill(pid, 0)
    if ok ~= nil then return true end
    -- TCP fallback to 8421
    local alive = false
    tcp:connect("127.0.0.1", 8421, function(err) alive = not err; ... end)
    vim.wait(100, function() return alive ~= nil end, 10)
    ...
    return alive
end

Three issues:

1. Dead PID falls into the wrong question. On Unix, dead PID makes uv.kill return nil, then we fall into the TCP fallback that asks "is anything on port 8421?" instead of "is this PID alive?" Different question. The whole point of your original PID check was to catch stale locks where the port has been reused by a different process. The fallback defeats that.

2. The fallback always returns false due to a variable-init bug. local alive = false (not nil). Then vim.wait(100, function() return alive ~= nil end, 10). Since false ~= nil is true, vim.wait returns in microseconds without pumping the TCP callback. The callback fires asynchronously after we've already returned, so the variable update is meaningless. I confirmed with vim.loop.hrtime() measurement, elapsed time is 0.001ms. Net effect: the fallback always returns false, and there's also a TCP socket leak in the non-nil branch (never closed).

3. Port 8421 is hardcoded. Wrong in multi mode where ports are OS-assigned, and is_pid_alive is supposed to be port-agnostic anyway.

4. Windows reality. I checked libuv source: uv_kill(pid, 0) has worked on Windows since v1.41 (2021), refined in v1.44 and v1.49. It maps to GetExitCodeProcess + WaitForSingleObject and returns 0 for live, UV_ESRCH for dead. Neovim 0.10+ bundles libuv 1.46+, so vim.loop.kill(pid, 0) behaves the same on Windows as on Unix. If you actually saw nil for a known-live PID on Windows, share your nvim version and :lua print(vim.loop.version_string()) and we'll look at it properly.

Recommendation: revert is_pid_alive to the original two-line form:

function M.is_pid_alive(pid)
    local ok = uv.kill(pid, 0)
    return ok ~= nil
end

libuv handles both platforms; no fallback needed.

Conflicts with main

Since this PR was opened, four PRs landed that touched the same files: #16 (default_theme), #22 (ELK), #23 (token auth in init.lua/lock.lua/remote.lua), #24 (lifecycle hooks). Concrete clashes:

• lock.lua: main has M.write(port, workspace, token) and mode 0600. This branch has the old 2-arg version.
• remote.lua: main has send_event(port, type, json, token). This branch has send_event(host, port, type, json) — different signature, different arg order.
• init.lua: main passes token and protected_paths to ls_server.start, generates a token at start, and uses a browser_url(port) helper everywhere.

The host config piece is still valuable and we still want to merge it. But the rebase isn't trivial. If you'd rather not deal with it, say the word and I'll rebase + fix is_pid_alive myself on a fresh branch, with you as Author on the resulting commits.

i'm gonna close this PR and just recreate it from first principles - the merge conflicts are pretty painful rn